Scheduled maintenance tasks
EMu includes a suite of utilities designed to maintain the efficient running of the System. Maintenance tasks are scheduled to run using the Crontab program.
Crontab is a task scheduler used by EMu System Administrators to run regular maintenance and other tasks.
A Crontab entry comprises six fields (separated by a space) in the order:
Crontab entry |
All possible values |
---|---|
Minute |
0 to 59 |
Hour |
0 to 23 |
Day of the month |
1 to 31 |
Month |
1 to 12 |
Day of the week |
0 to 6 (where Sunday = 0) |
Command |
A string executed by your shell at the specified time |
An example of a Crontab entry is:
|
An asterisk (*) can substitute for any of the date / time fields and represents all possible values for that field. Thus * in the day of the month field means that the task will run every day of the month.
A field can also contain a set of numbers separated by commas, or a range of numbers separated by a minus sign (e.g. 1-5 in the Day of the week field).
Note: You must open a command line session on the EMu server and log in with the username emu in order to edit the Crontab file.
Maintenance tasks are designed to keep the System working as efficiently as possible. The System Administrator determines which tasks are run and when.
Common EMu maintenance tasks are:
Running this task completes the indexing of new and modified records.
Note: To ensure fast System operation a record is only partially indexed when it is edited or inserted. Partially indexed records appear the same as fully indexed records to the user.
Typically this task is run daily, Monday through Friday.
Running this task rebuilds all indexes and compresses data, deleting obsolete records that have been marked for deletion and left after a record has been edited.
Note: The size of the Audit and Statistics modules will grow over time as more records are added to them. Since both modules have a very small / non-existent number of record changes it is not necessary to compact these tables as part of the weekly maintenance schedule. An option COMPACT="no" may be added to a module's emuoptions file (stored in the module directory on the EMu server) to skip the compaction of the module when maintenance is performed.
This task can also be run manually. See How to re-index a table for details.
Running this task deletes historic reports that were logged when a maintenance task was run by Crontab. The System Administrator determines the number of days that reports are retained.
Typically this task is run daily, Monday through Friday.
Running this task checks the status of each EMu table and produces a report.
This report should be checked daily to ensure that all tables are online and all maintenance tasks have been completed successfully.
Notification fields are used to inform users that something requires their attention. They are included in many EMu modules (notably the Loans, Events, Insurance and Movements modules, and any module with a Tasks tab) and are used to send an email notification to one or more people at a pre-determined date. In the Loans module, for instance, commencement and completion notification dates may be specified for a loan; the loans manager is automatically sent notification by email about the loan at these dates.
A notification comprises three components:
- The date on which people are to be notified.
- The people to be notified.
- A report to send as the notification.
The date and people to be notified are specified by a user in the relevant module (Loans, for example); reports are independent of the modules and are constructed from various files.
In order to generate notifications reports the emunotify script is run; it scans all notify fields and generates HTML files and an email message for everyone specified for any notification that has reached its due time and date. The email is sent and the HTML files are left on the server for viewing by a user through the View Notifications Admin Task.
Typically this task is run daily, Monday through Friday.
Two things must be done to add a local notification:
- The information about the notification must be included in the include file notify.pl in the local/etc/notify directory. See Include File Format for details.
- The files that will be used in the report must be generated. These files should be placed in the local/etc/notify/en directory. These are HTML files so that they can be displayed on the web and sent as email without requiring separate processing.
The following example is used for Conservations:
<TABLE WIDTH="75%" BORDER="0" cellspacing="0">
<TR>
<TD WIDTH="10%" nowrap bgcolor="#bgcolor#"><I><font face="Arial" size="3" color="#000080">Expected Completion Date:</font></I></TD>
<TD WIDTH="70%" bgcolor="#bgcolor#"><font face="Arial" size="3" color="#000080">#ReqRequestedCompletionDate# </font></TD>
</TR>
<TR>
<TD WIDTH="10%" nowrap><I><font face="Arial" size="3" color="#808080">IRN:</font></I></TD>
<TD WIDTH="70%"><font face="Arial" size="3" color="#808080">#irn#</font></TD>
</TR>
<TR>
<TD WIDTH="10%" nowrap><I><font face="Arial" size="3" color="#808080">Conservation Identifier: </font></I></TD>
<TD WIDTH="70%"><font face="Arial" size="3"color="#808080">#ReqConservationIdentifier#</font></TD>
</TR>
<TR>
<TD WIDTH="10%" nowrap><I><font face="Arial" size="3" color="#808080">Requested By:</font></I></TD>
<TD WIDTH="70%"><font face="Arial" size="3" color="#808080">#ReqRequestedByRef#</font></TD>
</TR>
<TR>
<TD WIDTH="10%" nowrap><I><font face="Arial" size="3" color="#808080">Date Requested:</font></I></TD>
<TD WIDTH="70%"><font face="Arial" size="3" color="#808080">#ReqDateRequested#</font></TD>
</TR>
<TR>
<TD WIDTH="10%" nowrap><i><font face="Arial" size="3" color="#808080">Notification Date:</font></i></TD>
<TD WIDTH="70%"><font face="Arial" size="3" color="#808080">#NotifyDate#</font></TD
</TR>
</TABLE>
Data is taken from each EMu record and inserted into the #ItemName# (e.g. #irn#) sections of the document.
The local include file (local/etc/notify/notify.pl
) format is as follows:
@LocalFields =
(
{
database => "eloans",
reffield => "DatCommenceNotifyRef_tab",
nested => 0,
datefield => "DatLoanCommenceNotifyDate",
overduefield => "",
report => "loan.htm",
header => "startloan.htm",
category => "outloan.htm",
datafields => ["irn", "InfLoanNumber", "InfDirection", "InfBorrowerLenderRef",
"InfReasonForLoan", "ObjObjectsLoanedRef_tab", "DatLoanCommencementDate",
"DatLoanDueDate"],
format => [\&none, \&none, \&none, \&address, \&none, \&count, \&date, \&date],
},
{
......
},
);
The explanation of each field is:
Field Name |
Explanation |
---|---|
|
The database to search for the notification. |
|
The field that contains the references to the Parties records for the people to be notified. |
|
Whether or not the |
|
The date field to be searched to match against the notify date. |
|
The field to be checked to determine if this action has been completed. |
|
The report body to be used for any notification matches. |
|
The report header to be placed above the report body for each notification match. |
|
A heading to be placed above all of the reports generated for this data field from this database. |
|
The data fields from the record that are used in the notification report. |
|
A processing routine to format the data field prior to putting it in the report. Each data field should have a corresponding format routine. |
The report to the user is output as follows:
category
header
report
header
report
....
The following data field format routines are defined:
Format |
Action |
---|---|
|
Do not change field data. |
|
Count the number of values in this field. |
|
Formats name as: Title Firstname Middlename_initial Surname. If this is blank, uses the organization field. |
|
Formats address as: |
|
Formats date in the dateorder as specified by the texpress dateorder environment variable. |
|
Formats the contents of a nested table where |
|
Formats the contents of a nested party reference table using the |
Special markers have been defined for passing information that is not contained in a record to the reports:
Marker |
Data |
Report Section Available In |
---|---|---|
|
Firstname Lastname. |
category, header |
|
The date of this report. This is a range (a week) for web reports and a single day for email. |
category, header |
|
The last date in the date range for this report. |
category, header |
|
The database that this report is from. |
header, report |
|
The notification date. |
report |
|
Sets the background colour to "E0E0E0" for web reports and to "FFFFFF" for email. |
header, report |
|
Available for email only and inserts the email address of the people to be notified. |
category, header |
|
Available for email only and inserts First name. |
category, header |
Access to the web notifications is set up through the eparties database. In order for a user to be able to view notifications, the Add EMuUserId field must be filled with the user's login id. The View Notification Admin Task checks the current user's id against the eparties database to determine the user's name and then displays any notifications they have in their default browser.
There are two possible explanations for this. The first is that they do not have any for the week. The server cleans up old HTML files that are more than seven days old. If a user does not have any notifications for a week, their file will no longer exist.
The second is that their user id has not been recorded in their Parties record.
The first thing to check is that the user's Parties record has an email address. If an address exists, a log exists in the logs/notify
directory that may help determine why the email failed. The logfile is named yyyy-mm-dd and the most recent week's worth of logs is stored on the server.
A likely reason for failure is that the sendemail script is unable to find sendmail on the smtp server. As a default it tries to connect to localhost unless the environment variable SMTPSERVER is set. It attempts to create a socket connection to sendmail on the smtp server. This could fail if the network does not allow access to that machine (try pinging it) or if the machine name supplied as the SMTPSERVER is incorrect. It could also fail if the network firewall is blocking connections to sendmail. Try to telnet to port 25 on the SMTPSERVER to ensure that it is possible to connect to sendmail.
The most likely reason for this is a typing error. Check that each of the #ItemName#
settings correctly accesses a defined column name from the back-end and ensure that any nested tables have the _tab extension on the column name.
The most likely reason for this is an HTML formatting error. View the source of the displayed page to determine the error and then correct it.
Each maintenance task generates a summary report.
- Open a command line session on the EMu server and log in with the username emu.
- Type
client [client]
to go to the required EMu client environment. - Type
cd etc
- Type
mkdir -p ../local/etc
- Type
cp crontab ../local/etc
- Type
cd ../local/etc
- Type
vi crontab
Make changes as required.
- Type
emu cron -i
- Open a command line session on the EMu server and log in with the username emu .
- Type
client [client]
to go to the required EMu client environment. - Type
cd etc
- Type
vi logging
- Edit the logging file with the required delivery details for each maintenance report. For example:
# Standard KE EMu daemons
batch mailto:admin@kesoftware.com
file:logs/batch/%year-%month-%day
reindex mailto:admin@kesoftware.com
file:logs/reindex/%year-%month-%day
Note: A maintenance report can be emailed to a specific address; saved as a text report in a specified directory; or printed directly on a specified printer.
- Save the logging file.
Note: By default, each report is automatically copied into an appropriate sub-directory of the logs directory. Retain these files for a history of the reports logged.
Note: The Rebuild Lookup Lists maintenance task has been replaced by a Lookup Lists Maintenance background service since EMu 4.1.